Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/standards/ansi/X3T9/area13/u9001041.txt

Text File | 1992-05-12 | 7.5 KB | 161 lines

This is one of the old Unix-OSD Group Messages that John Gallant sent to me
for posting on the SCSI BBS.  The date reflects when he sent it to me, not
the original message date.  John Lohmeyer
----------------------------------------------------------------------------
Date: Thu, 4 Jan 90 17:13:23 -0500
From: "John A. Gallant UEG" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Darryl's Unix OSD document

Hello All:

    Sorry for the lateness of this mail, but perhaps we can start some
discussion before the CAM meeting.  Remember we did say that we wanted to
start some e-mail discussions, a few months ago :-).

    I have a couple of issues and questions to raise about the initialization
parts of Darryl's proposal.  Overall I am in agreement with what Darryl has.

[All of Darryl's included text is indicated by a ">" at the beginning of the
line.  Do we all feel this is a good convention to follow ?.  It follows the
usenet posting convention.  JAG].


>Here is a proposed base for our group's OSD section efforts.
>
>        --Darryl Richman, Interactive Systems Corp.
>
>       6.5  UNIX_Operating_System
>
>       The UNIX CAM consists of 3 sets of drivers:  1) peripheral
>       drivers that are device class specific, 2) a configuration
>       driver and the XPT, and 3) SIMs that are HBA specific.  Each
>       member of these sets is treated as a UNIX driver and is
>       linked into the kernel.  The XPT and configuration driver
>       are OS vendor specific;  other drivers may come from any
>       source.
>
>       At kernel configuration and link time, a static table of
>       included peripheral drivers and SIMs is created and linked
>       into the configuration driver.

    A static table is definitly needed for the configuration/XPT/SIM points.
They are going to need knowledge of how to contact one another in a non link
time manor.  However a problem with the peripheral drivers will occur when
you have BSD based systems vs system V.  It probably will be good to have
entry/or other points for the drivers within this table.  Perhaps a default
call back or fatal error entry point, or simply a reset/restore point, I'm
not sure just what at this time.

>       6.5.1  Initialization
>
>       At system startup, the configuration driver's init function
>       is run from the ioinit array.  .......................

    With BSD based there no "ioinit" array, I belive that this is a sys V
concept, where there is one init routine per driver.  In BSD systems there
are the triplet routines probe/attach/slave.  These are called via the
configuration magic higher up in the Kernel.

>       .............................  It calls across the CAM
>       interface, through the XPT, to each SIM in turn, allowing
>       them to initialize.  The configuration driver obtains
>       information about each SIM, HBA, and target device detected
>       and maintains a table of these devices.  Note that
>       interrupts are disabled during the ioinit phase.

    I would expect them to be turned off during all the setup and init phases.

>       After all of the SIMs have initialized and the configuration
>       table has been filled in, the configuration driver invokes
>       the initialization routines for each peripheral driver.
>       This allows them to determine what devices are known and
>       make appropriate memory allocations and resource requests of
>       the XPT.

    This is were the I have the biggest problem.  With BSD based systems
the configuration magic sets up a number of data structures that are
used by a lot of the io/fs utilities.  Would this mean that these BSD based
systems would have to minic what the conf code is doing in the
configuration/XPT init handlers ?

    I think that what we had originaly discussed back in November(?), is
still valid.  The plan was that the first call to the XPT to initialize
itself from any peripheral driver would kick off the configuration
driver/XPT/SIM sequence.  Once the sequence had finished that initial
call from the peripheral driver would be completed.  Using the ioinit[]
array scheme the first call would come from the configuration driver.
In the BSD/configuraion scheme, the sequence of what peripheral drivers
is called before another is not known, so any peripheral driver could be
called before the configuration driver.

    I know that this is a little complicated but it does remove any
constraints on a predefined initialization sequence.

>
>       6.5.2  Accessing_the_XPT
>
>       6.5.2.1  From_the_Peripheral_Driver
>
>       All CAM requests to the XPT are placed through a single
>       function call:  void XPTaction(CCB *).  All returned status
>       information is obtained at the callback point via the CAM
>       and SCSI status fields.
>
>       The XPT also provides functions for obtaining resources for
>       the peripheral driver.  These are:  allocate and free ccb,
>       allocate and free cdb, allocate and free dma.  [Note that
>       these are not specified.  The completed document will have
>       to include definitions of these functions.]
>
>       6.5.2.2  From_the_SIM
>
>       The SIMs obtain requests from the XPT as they are passed
>       across from the peripheral driver, via a routine included in
>       the SIM's configuration information.  The field in the
>       configuration table is declared as
>       void (* SIMaction)(CCB *).  The XPT does not modify ccbs or
>       cdbs.  The XPT must intercept those ccbs which must be
>       redirected to the configuration driver (i.e., Path Inquiry,
>       Get Device Type, and Set Device Type).

    What worries me is that we have spent a lot of work making sure that the
SIMs do not have to worry about what is contained in a CDB.  Now we have the
XPT scanning each CCB for particular commands that need to be routed to
another driver, even though the configuration driver "works for the XPT".
Unfortunatly I don't have another way to handle this problem.  I do however
have an possible way to make the interception of CCBs a little simpler.
What about having the commands that are particular to the configuration driver/
XPT be within a range of values or have a particular bit, msb, set to signify
special routing is needed.

    This may be too much work considering that we only have about 7 commands,
but what if the list gets much larger ?  How many cascading if() statements
become too many ? Or how many angels can dance on the head of a pin .. ? Oops
sorry I became carried away :-).

>       6.5.3  Callback_on_Completion
>
>       The callback field in the ccb is a structure that is
>       platform specific, but always contains at least a callback
>       function pointer, named cbfcnp, and declared as
>       void (*cbfcnp)(CCB *).  It is allowed for the cbfcnp to
>       contain NULL, in which case no callback operation is
>       performed.

   Do we want to look at what the SIM does after the CCB is complete?  I would
expect that it would handle the next CCB on its queue.  But what if its queue
is empty, do we want it to call back to the XPT to allow another SIM to do
something ?  Or would it be better to have each SIM only handle its particular
queue, and have the other SIMs on interrupts handle theirs?  Could we get into
a dead lock condition where everybody is waiting for an event to start off
their queue ?

John A. Gallant                        [e-mail]
Senior Software Engineer - Ultrix Engineering Group
Digitial Equipment Corp.   [phone]

    "A beautiful theory, killed by a nasty, ugly, little fact."
    Thomas H. Huxly